Comments
-
Is it still possible to do this with sonicwaves?
-
I've disabled the NAT rule and set the access rule to discard. However ports scans still show UDP Open|Filtered and TCP shows filtered. This happens regardless if the access rule is set to deny or discard.
-
@BWC just says "Management NAT policy". We use local users on the sonicwall for management. I can't edit/remove the access rule or the NAT rule. I imagine I could go into the /diag page to allow me to delete these rules but as always I question if these are there for something I haven't considered.
-
@bwc just says "Management NAT policy". We use local users on the sonicwall for management. I can't edit/remove the access rule or the NAT rule. I imagine I could go into the /diag page to allow me to delete these rules but as always I question if these are there for something I haven't considered.
-
@BWC No sonicwall switch on this firewall. I should correct my statement above, we do have RADIUS(NPS) implemented for a virtual access point but that's it.
-
I did find a default NAT rule which I believe is likely the cause of this however why was this rule auto added? We never used RADIUS. Is this a standard out of the box thing?
-
@BWC I did come across that option however I was reluctant to go that route if there was another way. I generally stay out of the internal settings page unless it's necessary since I'm a bumbling idiot when it comes to most of those settings.
-
We have just 3 firewalls, with 2 more in the near future so maybe it's not for us. Regarding the notification, is there any more details NSM would show or log? It appears our WAN dropped but our upstream provider who monitors the connection reported nothing. Just trying to determine if this was a legit WAN down moment of…
-
I got this notion in my head from this statement: Every single interface on the firewall is separated by using VLANs internally. By default, it starts at 2. In SonicOS 7, the default vlan id starts at 3968. If you are configuring/using VLAN sub-interfaces on the switch directly connected to the firewall using the same…
-
I've sorted this out. They were two seperate issues/causes. I incresed the max connections on the receive connector and this has so far eliminated the warning about connection loss. I also discoverd the firewall was attempting to send email alerts but was set to authenticated SMTP. Changing to no authentication cleared…
-
The listening device is connected via switch on the same VLAN as the traffic I intend to capture.
-
I should add that this is using TLS, and I should be able to see a TLS handshake between the ESA and mail server rather than the actual SMTP traffic. I do not see this though.
-
I think this may be a part of the issue. The latest event I've gotten on the exchange server says just that. The maximum number of connections has been reached. This error is on the anonymous relay connector. What I find odd is that based on what I mentioned above is why was I getting the error on the default frontend…
-
@BWC Upon further checking, we do not have SMTP auth configured on the appliance. I'm confused because the original error on the email server was referring to the default frontend end receive connector but this connector is set for anonymous users and why would it be passing credentials for authentication if it's not…
-
@BWC It appears we are using authentication however for unknown reason we have an anonymous relay connector for the ESA specifically as well. The logs show the username for the ESA is what is generating the 2nd error I mentioned above however there's only two of us that have access to make changes and neither have made any…